User Interface Design Support Tools and Critiquing

Current user interface tools provide limited support when it comes to evaluation and usability testing. By adding a critiquing component with evaluation capabilities to the graphical layout tool, design flaws might be detected and comments and critique generated. Although prototypes of such systems have been implemented, little research has investigated how the critiquing component should behave – what, how and when to critique. This paper has two main objectives: to present the status of our current work and to argue for our view of the contents of a design support tool. A critiquing component implemented by us is described, and preliminary results from a project in progress is presented. We implicitly address the question of what methodology to use in HCI related research. A lot of work concerning design support tools tend to focus on functionality, technical innovations and architectures, forgetting the importance of usability and human factors. By combining technical and practical experience with empirical studies and psychological evidence we strive for tools with usefulness as a main goal. tor, the words of the design language are the interface elements (buttons, labels, listboxes, etc.) and sentences are composed by the layout and the elements’ attributes (colour, shape, etc.). Even higher levels of languages exist, where semantics, system design arguments or user-task information is added [17, 24]. In this paper, we will call a design tool which offers high-level specification (i.e. a user interface builder (UIB) with WYSIWYG editing, or a tool utilising a formal notation) and some means of evaluation or guideline support a design support tool (DST). The power of a built-in critiquing component, if only just for taking care of the purely static, syntactic design flaws, has been shown [3, 11, 14]. However, a lot of work is still to be done in this area to provide the designers with useful DSTs. What functionality is needed? Should the tool support some method/notation? What is the desired behaviour of a DST? How should the UI design work be integrated in a software development environment? We are focusing on the critiquing component of a DST, and especially the behaviour (critiquing strategies) it should have. This paper has two main objectives: to account for the status of our current research and to present our view of a future DST. We achieve this by: 1)presenting results of our own, i.e. a description of a critiquing component recently implemented by us, 2)describing some preliminary results from a project in progress, and 3)giving an overview of related research and discussing implications for future work. Unpublished Manuscript. Appeared in a local graduate student conference: Ericsson, M. User Interface Design Support Tools and Critiquing, In Proceedings of the 4th Annual IDA Conference on Computer and Information Science, Dept. of Computer and Information Science, Linköping University, Sweden, March, 1994. Local graduate student conference. 2 2. Design Support and Critiquing The design process might be supported using a lot of different methods and techniques, depending on the type of main goal. We focus on two main themes in user interface design – creation (the creation and implementation of the UI), and evaluation (measuring guideline compliance, interface style consistency, usability etc.). Other issues not primarily covered in this paper are: robustness testing, maintenance, requirements specification, etc. Productivity and efficiency might be increased through the usage of a graphical design tool like an UIB, instead of using toolkits and source code libraries [15]. This might also contribute with a small degree of consistency checking if the UIB is based on a set of predefined widgets and layout operations. Other effects of UIB usage might be increased effectivity (i.e. productivity), easier maintenance and better reusability [15]. 2.1 Critiquing as Design Support By adding an expert system module with critiquing capacities to the UIB, the designer’s work might be automatically inspected and commented upon, thereby indicating possible design flaws. Several research prototypes of design support tools have been implemented, not only for UI design [3, 6, 13]. Most critiquing approaches have been analytic, i.e. the component checks the designer’s interface with respect to predefined rules. They have also been purely static, inspecting only the syntactic layout of the interface. Dynamic or task-related aspects has not been handled. We believe that a built-in critic is a step towards a more usable design support tool. Even if only syntactic information is processed, productivity and consistency might be increased. Critiquing Strategies and Behaviour When dealing with critiquing system, the expert system techniques and control knowledge are not the only important factors. The behaviour of a critic is primarily defined by the critiquing strategies used – the factors defining what and when to critique and how to present the critique. Using the terminology by Löwgren and Laurén [12], the most important behavioural dimensions of a critic are the following: ■ Eagerness Should the system immediately point out problems or wait until the user asks for an evaluation? (Active/Passive) ■ Interactivity Should the system generate one-off comments only or should the user be able to investigate the rationale behind comments? (Education/Performance) ■ Level On what level should the critique be given (task, semantic, syntactic, etc.)? ■ Constructivity Should the system only point out problems or should it also suggest (and carry out) solutions? ■ Modalities When, how and in what combinations should textual, graphical and audible presentation be used? ■ Tailorability Should it be possible to tailor the system, e.g. skipping aspects, focusing on sub-parts. (Adaption, Focus) Current research concerning UI evaluation critiquing has not addressed these issues properly. Neither the usefulness of a critiquing tool nor the necessary and sufficient requirements for its behaviour has been investigated. We believe that this area is of great importance for a usable DST to be developed. 3. CRUISE – a Critiquing Component As a first practical step towards a complete DST we have developed and implemented a critiquing component shell called CRUISE [2]. From an input consisting of a UI description together with a definition of a set of evaluation rules, the system generates comments, by applying the rules on the UI description, as shown in figure 1. The CRUISE system is intended to be the critiquing component in a future DST, providing mechanisms for interactive critique and design support. The development was influenced by ideas from the KRI system by Löwgren [13], with mainly technical differences: portability and possibility of future integration were considered highly important for us. CRUISE was therefore implemented in a standard UNIX environment, using the C language, the parser tools bison and flex and a set of public domain tools. 3.1 Functionality and System Overview CRUISE is a special-purpose, hybrid expert system shell for static, analytic evaluation. The core is a standard production system, augmented with object-oriented data structures and a language providing rules and imperative constructs. Although the current system is a stand-alone application, the intention has been to prepare it for future integration.